Release 10.1A: OpenEdge Development:
ADM and SmartObjects

SmartDataObject deployment files

The ADM support files are shipped only with the Windows versions of the product. This is because you normally develop SmartObjects only with the AppBuilder, which generates a great deal of code for SmartObjects. Because the include files and super procedures that form the ADM become in effect a part of the final application, it is essential you use the same version of those files to build and run your application on all platforms. As a result, you must port needed super procedures to each deployment platform along with the application code. To test SmartDataObjects on an AppServer on which the Progress software is not installed, you must put these files into an adm2 directory on that machine relative to its PROPATH.

You need the following super procedures to run standard SmartDataObjects on an AppServer, either from a Progress client, from WebSpeed®, or from a non-Progress client such as Java:

smart.r
query.r
data.r

To facilitate testing distributed applications on a single Windows NT workstation (where you can run both a Progress client and a Progress AppServer session), these three super procedures reside in both the tty directory and the gui directory.

You must move all SmartDataObjects to be run on an AppServer to that machine. Usually you do not need to recompile the super procedures or SmartDataObjects on the target machine, unless it is a platform to which Progress .r code is not portable. However, if it is necessary or desirable to recompile the SmartObject super procedures or the application’s SmartObjects on the target machine, you also must move the following source files, as well as the custom subdirectory and its contents, to that machine, in a src\adm2 directory relative to the PROPATH:

smart.i
query.i
data.i
smrtprop.i
qryprop.i
dataprop.i
smrtprto.i
qryprto.i
dataprto.i
smart.p
query.p
data.p

When you run a SmartDataObject on an AppServer, the supporting super procedures smart.r, query.r, and data.r are started automatically, just as on the client, and are left running in support of any SmartDataObjects that are run for the duration of that AppServer session. All the super procedures run stateless, without maintaining any data specific to an individual client, thus the same AppServer process can service several clients in succession, even when each client expects to have exclusive use of that AppServer for the duration of its connection. As a result, your application incurs the overhead of starting super procedures once per AppServer session. (You can even run these procedures persistently as part of the session startup.)